Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upgraded various maven plugin versions to latest available. #1453

Merged
merged 4 commits into from
Jan 30, 2024
Merged

Upgraded various maven plugin versions to latest available. #1453

merged 4 commits into from
Jan 30, 2024

Conversation

archenroot
Copy link
Member

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

@saudet
Copy link
Member

saudet commented Dec 29, 2023

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

Don't do that, Groovy as used by Gradle doesn't support 1.8 features very well

@archenroot
Copy link
Member Author

Ok let me fix it. I did it as using Java 21 where 1.7 is not supported anymore 1.8 will be using jdk 17

@saudet
Copy link
Member

saudet commented Dec 29, 2023 via email

@archenroot
Copy link
Member Author

I reverted back the source and target versions to 1.7

@archenroot archenroot force-pushed the maven-infra-plugins-version-bump branch from 305b6ec to 0d4deb2 Compare December 29, 2023 10:47
@HGuillemet
Copy link
Collaborator

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

Don't do that, Groovy as used by Gradle doesn't support 1.8 features very well

Are you sure this is still an issue ? What 's the problem exactly ?
Gradle users work with Groovy DSL on Java project written in Java 1.8, 11 or 17 for years.

@saudet
Copy link
Member

saudet commented Dec 30, 2023

Yes, I'm sure: https://docs.gradle.org/current/userguide/validation_problems.html#implementation_unknown

@HGuillemet
Copy link
Collaborator

What you linked is related to the use of lambdas in gradle plugins. I don't think it's related to the version of Java javacpp itself is written with. Or did I miss something ?

@saudet
Copy link
Member

saudet commented Dec 30, 2023 •
edited
Loading

If you can figure out a nicer way to make sure the build fails on lambda expressions, we could add that instead

@HGuillemet
Copy link
Collaborator

The build of what ?
I need an example of failure due to lambda expression to understand what's going on, why we are stuck with a 12+ years old version of Java, and look for a possible solution.

@saudet
Copy link
Member

saudet commented Dec 30, 2023

The build for JavaCPP, we can't use lambda expressions in it, see issue bytedeco/gradle-javacpp#23

@saudet
Copy link
Member

saudet commented Dec 31, 2023

And there's most likely similar issues with Android, Kotlin, Scala, etc, so until we have a really good reason to move away from Java SE 7, I'll just stick with it.

@archenroot archenroot force-pushed the maven-infra-plugins-version-bump branch 4 times, most recently from 6e24bac to 97c7701 Compare December 31, 2023 16:11
@archenroot archenroot force-pushed the maven-infra-plugins-version-bump branch from 97c7701 to a7786a3 Compare December 31, 2023 16:20
@archenroot
Copy link
Member Author

Maybe one of the reasons/ideas to upgrade to at least 1.8 is to use latest graalvm-21 (and later in future) and start building native-images for the code base, although not sure what are your long-term plans.

@saudet
Copy link
Member

saudet commented Jan 1, 2024

I'm not having any issues with GraalVM 21. What error do you get when running this sample code?
https://github.com/bytedeco/sample-projects/tree/master/opencv-stitching-native

@archenroot
Copy link
Member Author

archenroot commented Jan 1, 2024 •
edited
Loading

@saudet - I switched to Oracle GraalVM 21.0.1 (I use SDKMAN to managed different version simultaneously)
image
I got an error:

[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Source option 6 is no longer supported. Use 8 or later.
[ERROR] Target option 6 is no longer supported. Use 8 or later.

So I upgraded maven-compiler-plugin to 3.12.1 which defaults to 8:
image

And I got this build log(note the recommendations):

[WARNING] Major.Minor version mismatch between native-image-maven-plugin (21.2.0) and native-image executable (Unknown)
[INFO] Executing: /home/zangetsu/.sdkman/candidates/java/21.0.1-graal/lib/svm/bin/native-image -cp /home/zangetsu/.m2/repository/org/bytedeco/opencv-platform/4.5.5-1.5.7/opencv-platform-4.5.5-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas-platform/0.3.19-1.5.7/openblas-platform-0.3.19-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp-platform/1.5.7/javacpp-platform-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp/1.5.7/javacpp-1.5.7-linux-x86_64.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas/0.3.19-1.5.7/openblas-0.3.19-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas/0.3.19-1.5.7/openblas-0.3.19-1.5.7-linux-x86_64.jar:/home/zangetsu/.m2/repository/org/bytedeco/opencv/4.5.5-1.5.7/opencv-4.5.5-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp/1.5.7/javacpp-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/opencv/4.5.5-1.5.7/opencv-4.5.5-1.5.7-linux-x86_64.jar:/home/zangetsu/proj/public/bytedeco-sample-projects-archenroot/opencv-stitching-native/target/opencv-stitching-native-1.5.7.jar --no-fallback --allow-incomplete-classpath -H:Class=org.bytedeco.samples.Stitching -H:Name=stitching
Warning: Using a deprecated option --allow-incomplete-classpath from command line. Allowing an incomplete classpath is now the default. Use --link-at-build-time to report linking errors at image build time for a class or package.
Warning: The option '-H:Name=stitching' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
========================================================================================================================
GraalVM Native Image: Generating 'stitching' (executable)...
========================================================================================================================
[1/8] Initializing...                                                                                    (7.0s @ 0.56GB)
 Java version: 21.0.1+12, vendor version: Oracle GraalVM 21.0.1+12.1
 Graal compiler: optimization level: 2, target machine: x86-64-v3, PGO: ML-inferred
 C compiler: gcc (linux, x86_64, 11.4.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 1 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
------------------------------------------------------------------------------------------------------------------------
 1 experimental option(s) unlocked:
 - '-H:Name' (alternative API option(s): -o stitching; origin(s): command line)
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 26.49GB of memory (5.3% of 503.77GB system memory, determined at start)
 - 32 thread(s) (36.4% of 88 available processor(s), determined at start)
Found pending operations, continuing analysis.
[2/8] Performing analysis...  [*****]                                                                   (13.7s @ 0.93GB)
    5,347 reachable types   (79.8% of    6,702 total)
    5,314 reachable fields  (41.7% of   12,753 total)
   27,718 reachable methods (34.7% of   79,948 total)
    2,479 types,   205 fields, and 1,998 methods registered for reflection
    1,055 types,   145 fields, and 1,088 methods registered for JNI access
        4 native libraries: dl, pthread, rt, z
[3/8] Building universe...                                                                               (2.5s @ 1.91GB)
[4/8] Parsing methods...      [**]                                                                       (2.9s @ 2.25GB)
[5/8] Inlining methods...     [***]                                                                      (0.4s @ 1.29GB)
[6/8] Compiling methods...    [****]                                                                    (15.6s @ 0.98GB)
[7/8] Layouting methods...    [**]                                                                       (2.8s @ 1.27GB)
[8/8] Creating image...       [***]                                                                      (7.0s @ 1.00GB)
  12.11MB ( 6.88%) for code area:    15,985 compilation units
 161.39MB (91.61%) for image heap:  333,533 objects and 1,395 resources
   2.66MB ( 1.51%) for other data
 176.16MB in total
------------------------------------------------------------------------------------------------------------------------
Top 10 origins of code area:                                Top 10 object types in image heap:
   6.94MB java.base                                          141.97MB byte[] for embedded resources
   2.50MB svm.jar (Native Image)                               6.81MB byte[] for java.lang.String
1010.38kB opencv-4.5.5-1.5.7.jar                               3.13MB byte[] for code metadata
 464.54kB javacpp-1.5.7.jar                                    2.58MB java.lang.String
 407.95kB java.management                                      1.38MB java.lang.Class
 148.73kB java.logging                                         1.16MB com.oracle.svm.core.jni.access.JNINativeLinkage
 148.70kB com.oracle.svm.svm_enterprise                      629.01kB java.lang.Object[]
  91.16kB jdk.proxy4                                         444.73kB byte[] for general heap data
  73.54kB jdk.charsets                                       403.60kB heap alignment
  47.88kB jdk.proxy3                                         366.48kB byte[] for reflection metadata
 235.91kB for 15 more packages                                 2.56MB for 1076 more object types
                              Use '-H:+BuildReport' to create a report with more details.
------------------------------------------------------------------------------------------------------------------------
Security report:
 - Binary includes Java deserialization.
 - Use '--enable-sbom' to embed a Software Bill of Materials (SBOM) in the binary.
------------------------------------------------------------------------------------------------------------------------
Recommendations:
 G1GC: Use the G1 GC ('--gc=G1') for improved latency and throughput.
 PGO:  Use Profile-Guided Optimizations ('--pgo') for improved throughput.
 INIT: Adopt '--strict-image-heap' to prepare for the next GraalVM release.
 HEAP: Set max heap for improved and more predictable memory usage.
 CPU:  Enable more CPU features with '-march=native' for improved performance.
------------------------------------------------------------------------------------------------------------------------
                        3.3s (5.9% of total time) in 48 GCs | Peak RSS: 3.83GB | CPU load: 16.00
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
 /home/zangetsu/proj/public/bytedeco-sample-projects-archenroot/opencv-stitching-native/target/stitching (executable)
========================================================================================================================
Finished generating 'stitching' in 54.1s.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:05 min
[INFO] Finished at: 2024-01-01T13:10:30+01:00
[INFO] ------------------------------------------------------------------------

And I am capable to run the sample:
image

@archenroot
Copy link
Member Author

@saudet - the thing with graalvm is that latest v21 requires at least java 1.8 code...

@saudet
Copy link
Member

saudet commented Jan 1, 2024

Well, you've just tried it yourself and it works fine with classes compiled for Java SE 7, so there's no issues, right?

@HGuillemet
Copy link
Collaborator

HGuillemet commented Jan 23, 2024 •
edited
Loading

The build for JavaCPP, we can't use lambda expressions in it, see issue bytedeco/gradle-javacpp#23

This issue is very specific to plugin authoring in Java: gradle sometimes tracks the versions of codes to determine if the output of a task is up to date, like the code of the task itself. And it's apparently impossible to determine the version of a code written as a Java lambda expression. So we cannot write tasks as Java lambda expressions in Gradle plugin. Gradle plugins written in Kotlin or Groovy can use lambda expressions.
You already did the modification in JavaCPP Gradle plugin to remove lambdas.

So this issue does not prevent JavaCPP itself to be written in Java 8+ and to contain lambdas. And does not prevent JavaCPP Gradle plugin to be written in Java 8 either as long as tasks are not written as lambdas.

Java 7 bytecode is still supported by OpenJDK 21 but we cannot target 7 with javac anymore. So we need Java 17- to compile JavaCPP.

I don't know anything about GraalVM, but I guess it's the same ?

I doubt Android or any current technology would cause any problem if JavaCPP is targetted to Java 8 or 11 but in the other hand, as long as JavaCPP is in "maintenance" mode and that all platform still can run Java 7 bytecode, there is little reason to upgrade.

@saudet saudet merged commit 5ad9ea5 into bytedeco:master Jan 30, 2024
1 check passed
@HGuillemet HGuillemet mentioned this pull request Apr 6, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@saudet saudet saudet approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@archenroot @saudet @HGuillemet